1. Field of the Inventions
The present invention relates to network agents which relay traffic from a source to a destination and specifically to eliminating catastrophic loops.
2. Background Information
Certain network agents facilitate the transfer of information between two other network agents over a network and are often referred to as a source agent and a destination agent. They can include network appliances, applications and other systems. Amongst these are proxies, which serve as an intermediary between a source agent and a destination agent and often shield the destination agent from a potential hostile source agent or a source agent's identity from a questionable destination agent.
A transfer proxy or transfer agent serves as an independent intermediary network agent between a source agent and a destination agent. In general, a transfer proxy has little relationship to either source or destination agents although some Internet Service Provider's (ISP) offer a Hypertext Transfer Protocol (HTTP) transfer proxy for the exclusive use of their customers. In contrast, a protective proxy serves as an intermediary specifically designed to protect one and sometimes more destination agents. Protective proxies serve a similar function to firewalls but are typically protocol specific, protecting a destination agent using an application layer protocol. Protective proxies include monitoring agents that do not necessarily intervene in information transfer but simply monitor traffic and connection management appliances such as Engate MailSentinel™ by Engate Technology Corporation.
One of the great concerns in a system with multiple agents including proxies is the existence of loops. In environments such as email, email can be relayed through a number of mail transfer agents (MTAs). In the case of email, MTAs receive entire email messages and retransmit them to the next destination agent, which could be another MTA relaying the email message further, or to a mail server where an end user can read it. A web proxy operates similarly, in that HTTP requests are received and retransmitted to the next destination agent, which can be another proxy or a web server. In this case, the consequence of a loop is that a given message remains in limbo forever as it circulates through the loop. With each message entering the loop this problem increases proportionately. Most systems implement a “hop count” solution, whereby as part of the message, usually as part of the header, a count of how many systems have relayed the given message is included. When this hop count exceeds a threshold, the message is assumed to be lost in a loop and deleted without further relaying. Furthermore, the loops encountered tend to be on a message-by-message basis. For example, a loop may only occur when a sender sends an email message to joe@generic.com, so not all messages loop.
A protective proxy, in contrast, generally performs little to no routing, especially if it is designed to protect a single destination agent. As a result, in the configuration of a protective proxy, the network address or other connection information of the destination agent is specified. In such a case, the protective proxy is connected only to one destination agent and a permanent loop can occur due to misconfiguration.
For example, FIG. 1A (prior art) depicts a simple loop in a system whereby protective proxy 104 is misconfigured to relay traffic from a source agent 102 to itself rather than to the destination agent 106. (The intended connection is designated by a dotted line.) Often, the unintended misconfiguration is caused by machine names that are very similar. As a result, this type of misconfiguration can occur frequently. FIG. 1B (prior art) depicts a more complicated system where messages are passed between many protective proxies. In this example, a loop is introduced by protective proxy 116, not by unintentionally looping back to itself, but to protective proxy 114, rather than the intended destination agent 118.
Typically, the protective proxy is placed either physically or logically between a network agent and the Internet. In many ways, it functions as a protocol specific firewall. For example, a sentinel such as Engate MailSentinel™ by Engate Technology Corporation can be placed between the Internet and a mail server. It is designed to protect the mail server from unsolicited commercial email (UCE). Because protective proxies are typically assigned to a single destination agent or in some cases to a few destination agents, protective proxies are often streamlined to relay packets without necessarily having to fully understand the protocol being screened. For example, in the case of electronic mail (email; henceforth mail refers to electronic mail), a protective proxy needs to understand only those Simple Mail Transfer Protocol (SMTP) messages that are related specifically to mail delivery. Other SMTP messages, such as administrative messages, need not be understood and can merely be relayed to the mail server.
FIG. 2A (prior art) depicts a typical-scenario where protective proxy 204 monitors all mail to mail server 206. In operation when protective proxy 204 receives an email request from any MTA 202, it immediately requests a connection to mail server 206. By being a low level relay, protective proxy 204 enables MTA 202 and mail server 206 to communicate using an SMTP protocol without requiring protective proxy 204 to have the ability to interpret SMTP. When a mail message is determined to be undesirable, protective proxy 204 intervenes and either terminates all connections between MTA 202 and mail server 206 or completes the transactions between MTA 202 and mail server 206, independently reporting to MTA 202 that a bad message was attempted and also reporting to mail server 206 that the session should be aborted and ignored.
FIG. 3 (prior art) depicts the operation of a typical monitoring agent or equivalent transfer agent such as a proxy. Upon startup at step 302, the agent performs any required initialization at step 304. At step 306, the agent listens to a rendezvous port and typically binds a listening socket to this port. The agent then waits for an event at 308. This event can be an attempt to connect to the listening socket by an external agent such as an MTA or an unrelated event associated with other potential functions of the agent, such as internal communications, timers, interactions with a control interface or other stimuli. If at step 310, the event is determined to be of the latter category, the required service is performed at step 312, and the cycle repeats by returning to step 306. If on the other hand, the event results from an external agent that is contacting the rendezvous port, the connection is accepted at step 314, which when using a standard socket library causes both the external agent and the monitoring agent to continue the transaction on a port different than the rendezvous port. The monitoring agent can now communicate to the external agent through a transaction port which is often bound to a socket. Furthermore, a child process is spawned or forked, and after the spawning, the parent process closes the transaction socket and returns to listening at step 306 so that it might service new external agent requests before the current session is completed. Meanwhile the child process connects to its destination agent at step 332. It then proceeds to allow the service between the external agent and the destination agent to continue until completion at step 334. The child process then exits at step 336.
FIG. 4 (prior art) presents exemplary code implementing the basic components of the process described in FIG. 3, where listen_socket and connect_socket are functions built off the standard listen and connect socket commands.
FIG. 5A (prior art) shows how SMTP messages are passed between MTA 202 and mail server 206 through protective proxy 204. It should be noted that when MTA 202 first establishes connection 502 with protective proxy 204, protective proxy establishes connection 504 to mail server 206. However, if the protective proxy 204 is misconfigured to connect to itself a catastrophic loop can occur.
FIG. 2B depicts a system where protective proxy 204 is erroneously configured to connect to protective proxy 204 rather than mail server 206. In such a situation a single email can cause a catastrophic cascading failure. As shown in FIG. 5B (prior art), in this situation, when MTA 202 establishes connection 572 with protective proxy 204, it establishes connection 574 to protective proxy 204 rather than mail server 206, which is seen by protective proxy 204 as a connection from another MTA so it establishes connection 576 again to protective proxy 204, and so on. Eventually, protective proxy 204 runs out of resources and becomes unusable. While a simple solution is to determine the Internet Protocol (IP) address of protective proxy 204 and verify it does not relay to that IP address, there are situations in a Local Area Network (LAN) environment where the protective proxy is behind a firewall and is the recipient of port forwarding or is in the Demilitarized Zone (DMZ) of a firewall. In any case, the IP address seen externally is not the same IF address for which the protective proxy is configured. Such a solution would have limited utility.
The major difficulty with other approaches is that the catastrophic cascading failure takes place before any high level transaction occurs. Low level solutions may be a possibility but would necessitate modifications in lower levels of the communications stack or even the modification of the underlying operating system kernel. Furthermore, past techniques have relied on tagging forward moving messages with a hop count. However, for lightweight protective proxies, most of the protocol interpretation is left to the agent being protected. As a result, communications are established with the protected agent very early in the transaction if not immediately, thereby making hop counts impractical if the protocol does not explicitly support them.